A symbolic link can be viewed as a file, which contains the name of the target to which it points. Symbolic links in computer operating systems are a powerful file system object type, which allow the creation of alternate names for file resources. For example, a file named /usr/bin/X11/xint might have a symbolic link called /bin/xinit. The link allows the file to be accessed as /bin/xinit instead of its primary name of /usr/bin/X11/xinit. Symbolic links are frequently exploited on UNIX platforms to create simplified or unified file tree name spaces. For example, it is common in UNIX distributions from different vendors to encounter slightly different locations for a small number of system utilities. Administrators can create symbolic links on the varying platforms such that a utility is accessible by the same name across all the implementations. In this example of creating a unified name space, the link on each system type points to the actual location of that utility on the system. The use of symbolic links can create various computing system configurations with respect to locating and referencing system resources. In one instance, with the use of symbolic links, there can be multiple symbolic links on a system pointing to the same system resource. In another instance with multiple machines, there can be symbolic links with the same name on each system where each link has a different name for its target. This case could even exist if the target is in fact the same functional entity. As an example, one system may have a link /bin/ftp which points to the primary name of /usr/sbin/ftp, while another system may have a link /bin/ftp which refers to /usr/lbin/ftp. In both cases, the link points to the utility ftp, which happens to reside in different directories on the two systems. However, with the symbolic link, /bin/ftp can be used universally to access the ftp program. The possibility also exists that on one system a name might be a symbolic link while another the name is in fact the actual resource (primary name), and not a link. Take the case of the above example with ftp and add a third system where /bin/ftp is in fact the actual ftp program.
Although the symbolic link is a very powerful tool, the symbolic link contains no security relative to its target. In other words, a user can have unrestricted access to file system resources through the symbolic link. With symbolic links, the security permissions on the target to which it points are applied when accessing the target via the link. If permissions are changed (chmod) against the link name, then the permission changes occur on the link's target, not the link. This happens within the underlying file system implementation. Once an alternate name is created for a resource using a symbolic link, it is common to manage the target via the link, since usually the link was created to provide a more convenient name.
Implementing an external security manager with respect to symbolic links that provides enhanced access controls and has the benefits of centralized cross platform security administration on UNIX file resources presents major security challenges. With an external security manager, extended security policy is attached to various system resources like files. The auxiliary policy might reside in a database local to the target system or perhaps somewhere in a network. In an enterprise security model, there would likely be a centralized policy database that acts as a security template for a large collection of subscribing systems. Optimally, policy would be administered and applied based on common resource names including symbolic link names for resources. Additionally, the creation of policy would be possible independent of access to the subscribing system(s) where the policy would be enforced. Symbolic links add security challenges because they create the potential for multiple names and therefore multiple access paths to a file system resource. On some systems, a resource name might be a symbolic link while on another it may not. On some systems, there may be many symbolic links all pointing to the same object. In addition, any user on a UNIX system has the ability to create a symbolic link and point it at a file system resource. Such a creation only requires the permission to create a file resource and this permission is not subject to any security restrictions with respect to the target until an access is attempted against the target. The existence of multiple names, symbolic links versus actual resources, and the unbounded creation of new names for a given resource reduces the effectiveness of an external security manager if the security administrator has to be responsible for understanding the details of symbolic link ramifications. If the administrator has to have knowledge of all links, which names were links versus actual resources, and actually know of all newly created links in order to apply security policy with an external security manager, then administration would be too complex and the potential for security exposures would be high. Therefore an external security manager must be capable of handling environments with symbolic links, such that at a minimum, an administrator can apply security policy on one name for a resource without regard for what type of resource. That policy should be enforced for that resource whether it is accessed by the name used in the policy, or accessed using an alternate name for the resource which might be a symbolic link, or potentially the primary name in the case of the protected name being a symbolic link.
In current computing file systems there is a need for a file system security policy that can identify symbolic links that represent protected system resources. This security policy should provide for placing protections on a file system resource by placing the protections on one or more symbolic links that point to the file system resource. This security means should be able to detect all protected symbolic links that point to a specific system resource. The security policy should have the ability determine whether a file system resource is the object of a protected symbolic link. This security policy should be able to detect access attempts to a protected file system resource through symbolic links that point to the resource, but are not listed with the security policy. This detection should result in enforcement of the protected resource's protections when the attempted access to the resource is through an unprotected symbolic link pointing to that protected resource.